Windows: force UTF-8 code page for app and samples #2951
Conversation
|
Looks like we'll need equivalent changes for meson... |
|
Heh, Windows 10 LTSC is on 1806. Fedora has a UCRT toolchain. Pretty barebones though. |
Active/mainstream support ended for 1809 LTSC. I don't think it's reasonable to hold back (not only for this, but other possible Windows features) until 2029 when security/extended support for mission critical only devices ends? 21H2 is the oldest Windows 10 LTSC being actively supported ATM. Mind you, this will not stop the app from working, it just won't have non-ASCII support. Then again, it doesn't really have it today either since wchar_t was removed from the API... |
|
Just noticed this was for the executable and not the library. Fine with me. As far as the library goes, the removal of the wstring API ended up alienating many users as they build exiv2 with MinGW on Windows. |
|
Correct, this has no impact on the library itself. However, in the absence of the wstring API in the library, client apps are expected to do the same trick as well if they want to support non-ASCII filenames, meaning Windows 10 1903 is effectively the minimum supported version.
I don't think this is limited to MinGW - MSVC users would need to use the same manifest trick to force apps to run as UTF8. This is a platform thing, not a GCC vs MSVC thing. |
kmilos
force-pushed
the
kmilos/win_utf8
branch
from
66cf8a9
to
a913d8e
Compare
kmilos
force-pushed
the
kmilos/win_utf8
branch
2 times, most recently
from
074a688
to
b37759a
Compare
kmilos
force-pushed
the
kmilos/win_utf8
branch
from
b37759a
to
bd1fb71
Compare
See https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page
This should make Windows behaviour almost identical to *nix w.r.t UTF-8 everywhere, and simplifies/improves on the "wmain" wrapper solution.
NB: bumps minimum requirement to Windows 10 1903 (w/ 5th gen Broadwell HW cca 2015 and later), as well as building using UCRT only (default for MSVC for a while already; for MSYS2 this means UCRT64 or CLANG64 environments; cross-building from Ubuntu/Fedora is suspended due to missing UCRT toolchains).
Could be left in the backlog until these changed requirements are deemed to be acceptable.
(This doesn't address the missing wchar_t API in the library in any way - clients would expected to run in the UTF-8 code page as well.)